[Day 01] 什麼是設計模式 (Design Patterns) ? 開始學習Pattern前該知道的觀念

15th鐵人賽 design pattern c++ cpp

2023-09-13 23:39:29

1108 瀏覽

分享至

設計模式 (Design Patterns)

模式是處理某種情境之下的問題的解決方案
深入淺出設計模式, 2nd (p. 565)

Design patterns are typical solutions to commonly occurring problems in software design
While an algorithm always defines a clear set of actions that can achieve some goal, a pattern is a more high-level description of a solution
- a pattern is more like a blueprint: you can see what the result and its features are, but the exact order of implementation is up to you

[補充] Modularization

The process of decomposing a problem into small subproblems is the process of modularization
Some programs might have thousands or millions of lines and to manage such programs it becomes quite difficult as there might be too many of syntax errors or logical errors present in the program, so to manage such type of programs concept of modular programming approached
Each sub-module contains something necessary to execute only one aspect of the desired functionality.
Modular programming emphasis on breaking of large programs into small problems to increase the maintainability, readability of the code and to make the program handy to make any changes in future or to correct the errors

Elements of Design Pattern

Design patterns themselves follow a pattern (a "meta-pattern," if you will). Each pattern has:

The intent states the problem that the pattern addresses (用簡單幾句話說明這個模式的作用，也可以將它當成模式的定義)
The motivation is a scenario that illustrates the problem (用具體的場景來說明問題，以及此解決方案如何解決問題)
The applicability of a pattern describes the circumstances under which the pattern is appropriate; that is, when you should and shouldn't use it (說明何種情況該用此模式)
The structure of a pattern is normally displayed as some sort of object or class diagram (UML 類別圖表)
The participants in the pattern are the classes and objects that comprise it. Each class or object also has a list of responsibilities (模式裡的類別與物件，職責與角色)
The collaborations describe how classes and objects outside the pattern interact with the pattern (說明模式的參與者之間如何合作)
Consequences are the results of choosing a pattern, both positive and negative (模式可能造成的好或壞的後果)
The implementation of a pattern is a set of code that uses the pattern. It shows the details and tricks that are needed to make it work (實作細節及須注意的眉角)
The known uses section of a design pattern describes some object-oriented systems where the pattern is found. This provides some practical real-world examples you can use to get a closer grasp of the pattern (介紹這個模式在真正的物件導向系統裡面的使用範例)
The related patterns list other design patterns that are closely related (說明模式與模式之間的關係)

Types of Design Patterns

依使用目的分類

Creational Patterns: 與物件實例化有關，可解除用戶與物件間的耦合
These design patterns provide ways to create objects while hiding the creation logic, instead of instantiating objects directly using the new operator. This gives the program more flexibility in deciding which objects need to be created for a given use case
Structural Patterns: 可將類別或物件組合成更大的結構
These design patterns deal with class and object composition. The concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionality
Behavioral Patterns: 與類別和物件如何互動、及分配責任有關
These design patterns are specifically concerned with communication between objects

依作用範圍分類

Class Patterns: 說明如何用繼承來定義類別之間的關係
The tale of Class Patterns revolves around inheritance. These patterns focus on the establishment of relationships at compile-time through inheritance
Object Patterns: 說明物件之間的關係，主要是用組合來定義的
These patterns are more about objects' relationships, which are typically established at runtime through object composition. The primary focus here is to define ways to create and interrelate objects, ensuring flexibility in both the system's structure and its behavior

分類整理

Type	Creational Patterns	Structural Patterns	Behavioural Patterns
Class Patterns	Factory Method	Adapter (Class)	Template Method, Interpreter
Object Patterns	Singleton, Prototype, Builder, Abstract Factory	Adapter (Object), Bridge, Composite, Decorator, Facade, Flyweight, Proxy	Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor

[補充] Design Principle

單一職責原則 (Single Responsibility Principle)
- 一個類應該只有一個引起它變化的原因
- 每個類應該只負責一個職責或功能
開閉原則 (Open Closed Principle)
- 軟件實體（如類、模塊、函數等）應該對擴展開放，對修改封閉
- 新功能應該通過添加新代碼實現，而不是修改現有代碼
里氏替換原則 (Liskov Substitution Principle)
- 子類型必須能夠替換其基礎類型，而不會導致程式出錯
- 保證子類繼承父類時，其基本行為不變
介面隔離原則 (Interface Segregation Principles)
- 客戶端不應被迫依賴於它不使用的接口
- 將肥大的接口分割成多個獨立的接口
依賴反轉原則 (Dependency Inversion Principle)
- 高層模塊不應該依賴低層模塊，兩者都應該依賴抽象
- 抽象不應該依賴於細節，細節應該依賴於抽象
合成/聚合複用原則 (Composite/Aggregate Reuse Principle)
- 盡可能使用對象的合成/聚合，而不是繼承
- 通過組合形成新物件，比通過繼承更為靈活
迪米特法則 (Law of Demeter) / 最少知識原則 (Least Knowledge Principle)
- 一個物件應該僅僅知道其直接相依賴的物件，而非詳細了解其他物件的內部結構或行為
好萊塢原則 (Hollywood Principle)
- "別找我們，我們會找你" —— 這個原則可以避免「依賴腐敗」，讓低層組件將自己掛入到系統，由高層組件決定何時和如何使用這些低層組件 (與依賴反轉原則不太一樣，但兩者目的都是在解耦合)
KISS 原則 (Keep It Simple, Stupid)
- 當你進行設計時，盡量用最簡單的方式來解決問題。你應該把目標木在「簡化」上面，而不是「怎麼用模式來解決這個問題」
DRY 原則 (Don't Repeat Yourself)
- 避免程式碼中的重複，對於每一個知識點，都應該只有一個明確、單一的表示。當相同的邏輯或數據在多處出現，應該透過函數、類別或模組等手段將其抽象出來
YAGNI 原則 (You aren't gonna need it!)
- 應該在面臨確鑿的需求時，才實作相應的功能。換言之，就是不要實作那些現在用不到的東西，也不要因為未來可能需要的理由而事先實作。目的是為了避免浪費時間和資源去開發最終可能永遠不會使用到的功能

[補充] Abstract Data Type, ADT

Abstract Data type (ADT) is a type (or class) for objects whose behavior is defined by a set of values and a set of operations
The definition of ADT only mentions what operations are to be performed but not how these operations will be implemented

註: 這些內容是我翻閱書籍 (Head First Design Patterns 2nd)，搭配網路查找相關資料所整理成的筆記。有時間我再翻譯成更順口的中文來解釋 (使用 ChatGPT 翻出來的中文還是稍奇怪了點，故保留原文以免造成誤解)

[比較] 設計原則(Design Principle) & 設計模式(Design Patterns)

雖然這兩者都在軟體設計領域中被廣泛提及，但它們具有不同的定義和目的。以下是它們之間的關聯和差異：

定義
- 設計原則 (Design Principle)：這些是幫助指導軟體設計的高層次的指導方針。這些原則提供了一個框架，幫助開發者確保他們的軟體設計是靈活的、模組化的、可擴展的和可維護的
- 設計模式 (Design Patterns)：這些是軟體設計中的常見問題的解決方案。它們不是可以直接在程式中使用的代碼，而是設計藍圖，幫助解決一般性的問題
關聯
- 設計模式往往是設計原則的具體實現。也就是說，許多設計模式都是基於一個或多個設計原則來創建的。例如，觀察者模式實現了「依賴倒置原則」
層次和範圍
- 設計原則是更為廣泛和高層次的指導方針，它們適用於各種情況和上下文
- 設計模式則更具體，針對特定的問題和情境
目的
- 設計原則旨在建立一個好的軟體架構基礎，確保軟體設計的健康和持久性
- 設計模式提供特定問題的解決方案，使開發者能夠更容易、更快速地構建軟體

總的來說，設計原則和設計模式都是軟體工程中用來促進優秀設計的工具，但它們在概念上和實際應用上有所不同。了解它們之間的關係可以幫助開發者更好地設計和構建軟體